As announced on my French blog, I m attending Solutions Linux this week (10-12 May). I ll be on the Debian booth with a few other members of Debian France. If you re in Paris during those days, make sure to come by. I ll be pleased to meet you, and we ll be a bunch of Debian contributors ready to answer your questions. And if you feel like it, feel free to stop for a few hours and give us some help at the booth. It tends to be crowded and we re never enough to answer the questions. As usual, I ll come with a copy of the book Cahier de l Admin Debian (the one that I want to translate into English) to show, and I ll be glad to dedicate the book to whoever brings his copy with him/her. While speaking of conferences, this summer I m going to Banja Luka for DebConf 2011. I ve bought my plane tickets and I ll be there the whole week (24-31 july). Joining a DebConf is a completely different experience. DebConf is made by Debian people for Debian people. It s an opportunity to meet many of the people that you mainly know over IRC/email. And you don t need to be a hardcore Debian contributor to join. In fact, it s a great experience for anyone who just started contributing to Debian. Read this email of Asheesh Laroia as a proof. Note that the sponsored registration period has been extended up to the 17th of May. Register now! I m looking forward to DebConf11. On request of Stefano, I registered a Debian Rolling Bof. It will be a good occasion to see how far we are and to discuss future plans.

No comment Liked this article? Click here. My blog is Flattr-enabled.

This is just a quick note to say: Next week, I am going to be at: My goals for the conference:

• On Day 3, participate in a panel called How to keep and make productive libre graphics projects?
• Talk about the success of the recent Build It events.
• Learn more about the world of free software graphics app development.
• Enjoy the opportunity to speak French.
• Say 'hi' to old friends like Jon Phillips.
• Give chocolate to Michael Terry for staying positive on a recent gimp-deve thread.

I'm going to arrive in Montreal at 6:30am on Tuesday on an overnight Greyhound bus from Boston. So another goal:

• Make it through Tuesday without embarrassingly falling asleep in public.

If you want to say hi to me during the conference, email me and make sure we meet up!

Current mood: moved Today is an amazingly great day. I wrote a blog post about an event that I put together, and an attendee then followed-up by writing a long-form comment. The thing is, the attendee did a far better job of writing about the event than I did. The amount of emotional positive reinforcement that this comment gave me is hard to overstate. You can find it toward the end of the blog post but I hope you'll read the copy below. I am stunned and awed. I guess I have my work set out for me.

8----< CUT HERE >-----8

I have never written software for an open source project. I am not subscribed to any development mailing lists. I have not been in a chat room on IRC for months. Yet I was delighted to see this tweet from @torproject on 04/15/2011 https://blog.torproject.org/blog/vidalia-get-involved Join us in #vidalia on irc.oftc.net today at 13:00 UTC. The blog post described the Build It initiative for the Vidalia project, where people would be available to help you setup your build environment and compile the project. I have wanted to participate in open source projects for quite a while, but never really knew where to begin. I have experience (and enjoy) writing software. I am glad to learn the languages they are using. I know how to compile software. I m glad to learn their versioning system and build system. I looked into participating in several projects, but felt like I would be more of a burden than a help considering the relatively small amount that I was intending to contribute. I can generally figure anything out on my own, but it s nice to have somewhere to turn when you are struggling with something simple . I thought that this would be a perfect opportunity for me, since I already preach the use of Tor and Vidalia. I ve even demonstrated the bundle at a local LUG meeting. :) I joined the OFTC #vidalia room and waited nothing happened around 13:00 UTC, so I figured I d missed the event. They began around 13:30 UTC and walked us through the source code download process and compilation process. They directed our attention to the Volunteer page and the HACKING page. chiiph even suggested several simple OSX-specific tickets for me personally, since he knew that I was building on OSX. I ve already managed to contribute a patch for one ticket and am ready to begin a second ticket. I wouldn t have done it without help and feedback from chiiph and others. I am confident that there are many others who would be glad to help out with one or more of their favorite open source projects if they only had some place to begin. I hope that other project members or leaders offer a similar Build It events for their users. Jason Klein

The most common reaction to OpenHatch that I get is a mixture of enthusiasm and confusion. People say things like, I like the OpenHatch website. I haven t taken the time to sit down and understand it, though. If you want to a guided tour of the website, or to chat with OpenHatch contributors and fans, read the announcement and meet us on IRC!

Proposed timeline of the Release Team

We hope to have sorted out all the details and resolved the remaining blockers by the end of October, with the focus during November being on translation updates, testing and coordination with different teams to prepare the new release.
This means that it s possible to have a release out in time for Christmas, but to do this we need YOUR help. Please, squash bugs, write release notes, squash bugs, support our translators and squash some bugs.

Prospective Debian contributors typically follow this process:

1. Read the New Maintainers' Guide.
2. Find something they want to package.
3. Create a package.
4. Email the debian-mentors mailing list asking for someone to review the package, and if it passes review, upload it.
5. Feel increasingly lonely and sad, as the days pass without a reply on the list.
6. (Optional) Blame themselves when no one seems to care, when in fact they submitted a perfectly fine package.

Okay, so I'm exaggerating that last point. But I'm very interested in improving the culture of Debian, like I promised as follow-ups for that Debian for Shy People talk. I was talking about the email list on the #debian-mentors IRC channel. I got this vote of confidence from andrewsh:

<andrewsh> silence is bad

When there are humans involved, silence isn't always golden. So now I have a plan: Niels and I promised that any email to debian-mentors will be answered within four days. Maybe we'll say, "Sorry, we all seem to be busy!" Or maybe we'll say, "I'll try to review that next Thursday." The goal is to replace self-doubt and worry among contributors with feedback and clear expectations. (Thanks to Karen Rustad for help with editing.)

On January 30, 1998, Wired.com gushed about the ethical underpinnings of the free software movement. The movement was growing:

Netscape's bold move last week [was] to free the source code of its browser is a prime-time endorsement for no-cost, build-it-yourself software.

The free software movement was in its second decade. In the first decade, corporations learned to tolerate it. In the late '90s, a transition was underway. Red Hat was one of the first companies ostensibly founded on free software principles. But as free software grew, some were concerned that its name was holding it back. The article explains with a link to a page within gnu.org:

But "free software" is an ambiguous term - there is a difference in meaning between the cultures of PC-based proprietary systems and the Net-centric UNIX worlds.

Michael Stutz, the author of the piece, surveyed the writing of Eric S. Raymond and interviewed luminaries like Bob Young, Russell Nelson, and Marc Andreessen. The article is about the creation of a new term for the freely-reusable code produced by the free software movement.

As proponents of free software often point out, while this software can be free-of-cost - that is, gratis - the real issue is about freedom, or human liberty. So it is really freed software.

Yes, that's right -- freed software. The emphasis is in the original. Most of us know the names Eric S. Raymond and Russ Nelson as people involved early-on in the Open Source Initiative. I guess January 1998 is before they decided on the "open source" name. Today, the community is divided into people who think it's important to say "free software" and the rest who call it "open source." We'd all agree with the following statement from the article:

"Freed software is a big win for society in general," said Russell Nelson.

And that's today's random page from the history books.

What do you do when you have a technical question that you're embarrassed to ask? The first Sunday of Debconf, I led a birds of a feather (BoF) session called Debian for Shy People. The conference team scheduled it on "Debian Day," a pre-conference day that was open to the public and still had plenty of Debian Developers in attendance. I just uploaded the slides to the "Penta" page for the talk. I led it because of my own experience. In 2004 or so, I saw Debian as the cool kids' club, that awesome project that I wished I could be a part of. By 2006, I managed to get over myself, read the New Maintainer's Guide, and find a way to get involved. As of mid 2009, I am a full-blown Debian Developer. I have real ultimate power. But I sometimes do still feel hesitation akin to "Imposter Syndrome". (A bunch of people at Debconf didn't really believe I'm "shy," since I asked a lot of questions at the conference. At core, I don't naturally believe that the things I say are worth hearing, but I patch over this hesitation. Sometimes I speak too much, and then I feel ashamed of burdening everyone. But anyway, this is about Debconf not, me -- so moving on....) In the past year of being a Developer, one thing I've seen is that other contributors ask me privately for help. Rather than blast the public lists like debian-mentors, they email or IRC private-message me, or SMS me, or find me at a Linux Users Group event. I'm lucky to know these people, and they're lucky to have me as a safe person to ask questions of. Moreover, Debian is better because these people could move past their confusion to make a technical contribution. I began the BoF session by talking about when someone asked me for help. Then I asked, "How many of you have someone you can ask embarrassing questions of?" Of the forty people crammed into Schapiro 414, two people' raised their hands. One person put it plainly, "I don't know anyone else who does Debian." It reminded me of a fact that Karen discovered when she was doing market research for us at OpenHatch: the vast majority of free software programmers know zero other people who do free software. I had seen the figure; we even used it in a talk to try and convince venture capitalists to fund OpenHatch last year. But I didn't really feel it until I heard it from a room full of Debian contributors. I structured the BoF in two parts: First, I talked in front of some slides to set the tone properly, and then we enjoyed open discussion. As I was preparing thoes slides, Daniel Morais asked me, "What's the point of having the session? Why not just come up with some ideas, implement them, and not bother also talking about it at the conference?" I had considered this; I decided I wasn't self-confident enough to start implementing ideas without talking to people to make sure I wasn't the only one who saw a problem. But I discovered another benefit of giving the talk: people who want to make Debian more welcoming knew to reach out to me. So here are some thoughts that came from our discussion (and later discussions during the conference):

• We need better mentorship in Debian. Truly, mentorship is a personal relationship. Perhaps matching people up into one-on-one groups would be a good idea. KiBi said that doing so using OpenHatch (if we add mentorship-oriented features!) would be a reasonable way to do it.
• I've heard from quite a few people who would be willing to have more one-on-one relationships with mentees.
• Everyone (except Manoj) knows that Debian contributors are not born experts. It takes a process of learning and teaching to bring them up to speed.

I set up an Etherpad document on cjb's OpenEtherpad.org. This is what we learned together:

• "If your level of understanding might be low, but you want development help, then you might not know if #debian-devel is only for people who are already super involved and know everything and therefore you should feel embarrassed."
• People get anxious over their ability to speak English.
• Bikeshedding over patches can be a major detractor.
• "Asheesh talks too fast."

One idea I had before the BoF was to create a discussion area that was safe for all questions, even if they seem silly. We talked for a while about what name that would take, if it were to become a new IRC channel. We reached something of a conclusion, but in the conference that followed Emmet Hickory offered to help make the debian-mentors IRC channel friendlyer. I think that's the best direction to take things, so the next step is for him and me to write up what we want and send a note to the debian-mentors email list explaining our vision. In the Etherpad document, people discussed the idea of doing Debian discussion over XMPP (also known as Google Talk, also known as Jabber). We weren't sure how such a place would get critical mass; someone briefly mentioned the idea of an IRC/XMPP gateway. I actually think this discussion is along a very reeasonable path, namely discovering what discussion method(s) Debian contributors want to use. (That might explain why I'm now an admin on forums.debian.net.) We also briefly discussed the idea of an anonymous question-answering service. I realize now that I'm not going to be able to have time to run that, but I still think it'd be a really cool idea. Biella would remind me that Debian is already successful at bringing in new contributors. I agree! As a free software project, we have an enormous number of participants. This is a really good thing, and we're clearly doing something right. The purpose of this talk was to figure out how to make contributing to Debian less stressful for those who participate. Truly, a "Debian for Shy People" effort isn't about shy people. It's about the moments of self-doubt we all have in which we don't know what to do and are too embarrassed to ask. I think that if the project more friendly, we can find more participants, make better use of our current ones, and see improvements to our diversity. Whew, that was long. What do you think of all this?

Six months ago, I was talking with Kat. We were talking about talking. On imperfection Kat wrote:

<mindspillage> I think I have to be very very comfortable around someone to be able to be imperfect around them.
<mindspillage> (at least, without feeling horribly embarrassed about it)
<mindspillage> More so if what I'm doing is part of my identity.

It's safe to be bad at dancing, she explained; she doesn't consider herself a good dancer, so nothing's at risk. On flames I had recently written about diversity in free software. Kat showed me a piece she had written, but not yet published, on a similar topic. I thought she should simply publish the piece as-is. Instead, she worried:

<mindspillage> I feel like I have a hard time getting across what I think without coming across as antagonistic.

I've felt the same way. Years ago, I told my friend Venkatesh that had sent a flame to a mailing list we're both on. He retorted that my flames lack flame. So then I thought about why I might feel I've written a flame, even when no one else felt that way. I wrote to Kat:

<paulproteus> Expressing oneself is a frustrating experience.
<paulproteus> It may seem like you're taking this out on other people.
<paulproteus> In fact, you're just frustrated.
<paulproteus> And fighting (successfully) your own urges to just be quiet.
<paulproteus> So at the end you'll feel like you fought a battle, and that seems like you wrote something that others would feel is antagonistic.

Maybe for Kat's writing and my "flames", there was some sort of antagonistic process in which we fought ourselves. That fight doesn't have a lot to do with the resulting text, so it's invisible to the reader. I think this process might leave us vulnerable in another way: if our urges to stay quiet come from a sense of isolation, and we manage to stay quiet about that feeling, no one will sympathize with us. We'll appear to be healthy, active participants in a conversation where we express ourselves. Other people with a similar "process" for self-expression won't get a chance to empathize. (This is why I'm interested in putting together a Debian for Shy People caucus. I hope my Debconf proposal for a Birds of a Feather session is accepted!) On finding a way out We concluded on a happy note:

<mindspillage> I haven't been answering Wikimedia mail for a while. Then I figured out that I don't have to use my real name, so I don't have to answer as someone with responsibility, I can just be some random volunteer.
<mindspillage> Most of it is silly and trivial. But sometimes I am really able to address someone's concern or change someone's mind, and I forget how good that feels.
<mindspillage> (There are some real jerks too.)
<mindspillage> I got someone who was being snarky to apologize for being so rude. That was kind of awesome. Sometimes it doesn't take very much to make me happy.

P.S. A note from the archives Apparently, for me, speaking French is exempt from the above restrictions.

Most of my email comes to me via mailing lists. When someone asks a question or starts a discussion, I used to jump at the chance to be the first to reply with an answer. I don't want to unsubscribe; often, I know something that can move the conversation forward or help someone out. But I'm trying to allocate more time for myself away from computing these days. So now I let these discussions mature a little before I see them. All mailing list messages are delivered to a folder called OneDayDelayed. Every night, my server moves those messages to my INBOX. If someone else has already contributed what I would have, perfect! If not, I still have a chance to participate. Sometimes, if I have a long backlog of email, I disable that cron job, sometimes for up to two weeks. Being able to turn the cron job on and off really helps; when I have time to deal with mailing lists, I do. Otherwise, I know the messages will be there when I do have time. Since this OneDayDelayed change, I've gained have a sense of calmness and distance from them. I like that. (Note that if you add me to the CC: line of a mailing list thread, I will see your message immediately, for better or for worse.)

This note goes out to the maintainers and contributors of Free and open source projects. (Cross-posted at the OpenHatch blog.) I recently had the chance to look at Mozilla Quality Assurance's research into the people who help out with testing versions of Firefox. I saw numbers that really spoke to my experience as a volunteer. On one hand, the vast majority of people put in three or fewer hours a week, most of whom put in one hour or fewer (such as zero). On the other hand, a huge number wish they could put in a lot more: Now imagine you're that one-hour-a-week contributor. You have all these other bits of your life tugging at your time. You want to make sure that when you sit down to work on free software, you're doing something that really helps out. Otherwise, not only will you feel bad that you aren't giving free software as much time as you wish, you'll feel bad that you're not even making a difference. In my experience, even reading the project mailing list counts toward that time you're putting into the project. But that doesn't feel productive. So fellow contributors, I have a request for you: Would you be willing to make it super easy for someone to stand waiting, on guard, for instructions from you? Imagine if all they had to do is click a button on your website, write a little bit of info about what they could do, and you would suggest something for them to work on. Maybe you can offer them a bitesize bug to fix, or maybe you need someone to download and test the latest version before you release it. If you're handing out assignments, then part-time contributors don't have to spend their time figuring out what they should do. I want to tell you that I can give you such a button. It would look like this: To get it, you just have to add a little snippet of HTML to your project website. Just go to the OpenHatch project list. and find your project. If it's not there yet, search for it, and click the link to create it. Then find the box labeled "Have your own website?" and click. Ta-da! HTML source code you can copy-paste. Since OpenHatch itself is an open source project, we added the button to our own "source code, etc." page. When people click it, they appear in a list of "People willing to help" on your project's OpenHatch page. Like all the friendly faces on the Gwibber page. Would you try it, too?

Two months ago, I explained how cosmetic carbon copy could allow you to list recipients in a message who never receive a copy. Today, thanks to John Stumpo's writing talent and Wes Filardo's IETF-NG, an Internet-Draft informational document has been published. IETF didn't like it enough to accept it as an April 1 RFC. (I do actually hope that one day someone will submit a modified version to IETF as a rest-of-the-year RFC.) Slashdot took note! In first visible comment, an Anonymous Coward writes:

Although it is an April Fool's...this would actually be useful.

Other highlights from the Slashdot discussion:

• An Anonymous Coward writes about an existing implementation.
• quantumplacet actually corrects me on my recollection of the standard.
• Delusion_ complains of April Fool's Day, "I hate today."

Dear New Yorkers, I'm going to speak at Free Culture NYU about my current project, OpenHatch. Please come out! To get there:

• 8 PM, Monday 3/22
• Kimmel 904 at NYU (map)
• More info

If you need help finding the place, call my cell phone. (Visit the freeculture.org contact page for that.)

(Cross-posted from the OpenHatch blog.) I remember working on my first big group programming project back in college. The project involved some web scraping work; I enthusiastically took charge of that part. But a few weeks in, my code just wasn t working. I felt frustrated and helpless I m supposed to be the scraping expert, so why couldn t I fix the problems? I retreated into hiding and didn t want to think about the group of people or the project. A week later, I feebly ran svn update to see how the project had progressed. Oh! I exclaimed to myself. Someone made the data importer work! I felt a rush of relief. (While writing this paragraph, I sighed again remembering it.) When I talked to my teammate George, he mentioned off-handedly that he had fixed it. He didn t feel any of the anguish I felt or assign me the blame I thought I deserved. I guess if I had just asked for help earlier, I could have skipped the feelings of inadequacy entirely and George would have just fixed the bug. Half a decade later, I feel the same dread about the lack of Maildir support in Alpine. The bug is three years old! Ugh. This time, I m going to ask for help. So I listed the issue on the Alpine project page on OpenHatch. To put it there, here s what I did:

• I logged into OpenHatch and added Alpine to my list of projects.
• I followed the link on my profile to the Alpine project page.
• I answered the last question, What is a bug or issue with Alpine that you ve been putting off, neglecting, or just plain avoiding?

For those of you who work on Free Software projects, what are the issues that drain you the same way? No bug tracker I ve seen has a field that says, I m avoiding working on this, and that sucks. To say that, list the issue on your project s OpenHatch page. So join in! What are the issues you don t want to think about? Once you share them, maybe a fellow developer or a new contributor will come by and help you out. Head to OpenHatch and let the world know. P.S. Do you have any ideas about how we can make these project pages more useful? Let us know! P.P.S. Dear Joey Hess and everyone else, sorry that Alpine still doesn t have Maildir support.

Should universities switch away from hosting their own email and join the Google bandwagon? Adi Kamdar wrote to the Students for Free Culture discussion mailing list linking us to a Yale Daily News article discussing an "almost-definite" switch for Yale to Google Apps for Education. Adi asked for thoughts, so here are mine.

Privacy One interesting thing about the Gmail option is that, when deployed for all students, students have no choice but to let Google read their official email. Some students might take part in activism that they want to shield from Google, a corporation with its own interests, or the attackers that attempt to break into Google's systems (see the recent attacks from crafty pro-Chinese-government hacktivists). Before a switch to Gmail, each student could choose if Google was the kind of company they wanted to share their email with. After a switch to Google Apps, the choice is made for them. But this highlights a different issue: Before a switch to Google, students have no choice but to let university administrators read their official email. That's not necessarily optimal, either. Others have pointed out in this thread that this option comes with legal advantages with regard to privacy law. At least that's some consolation. It's still true that students can encrypt their email and make it difficult for any eavesdropper to figure out the bodies of their emails. But that's no use for hiding the identities of the people with whom they communicate -- no email crypto I know hides email addresses.

Software freedom and open standards This is juxtaposed against another difficult situation: Matt Senate wrote about the sucky Squirrelmail system that Berkeley uses (used?) for webmail. The fact that SquirrelMail is Free Software is small consolation for Matt. From his perspective, because it's a hosted web application, he has no more freedom than he would have with Gmail. At least Berkeley's IMAP server followed standards! That's more than we can say for the Gmail IMAP server, which is famous for basically supporting just enough IMAP for Microsoft Outlook to work. But standards compliance is small consolation. If the university email server "properly" supports IMAP, but isn't fast or doesn't provide the new extensions that make threading or search speedy, it's not much relief to know that you can use any client you want to slowly read your email.

Internet history Truth be told, University-hosted Internet services are based on what you might call the original Internet perspective. The Internet began as a network of networks. A University was a network island unto itself, running its own email, news, and Ethernet services. When inter-network connection was available, you can email people at other institutions. When it wasn't, well -- the Internet is a useful tool, but it's down right now. "Don't worry," the admins might tell you, "you can still read your email with PINE." It used to be that inter-network connectivity was icing on top of the "real" network a person used. Today, inter-network connectivity is the whole point of a network connection. How embarrassing for each individual network! To test if our connections are working, we skip right over the local content and point our web browsers at a search engine. Users today aren't satisfied to read their email from imap.institution.edu and read USENET news-- they thirst for real-time access resources available beyond the university. Students weren't interested in the J-Stream service I helped set up at Johns Hopkins; instead they mostly posted and watched videos at YouTube. They don't really care if the the student-oriented wiki is based on campus or instead halfway across the globe (say, in Japan). The original Internet was based on autonomous networks and opt-in routing. But eventually, all the networks opted in. Users drive everything, and when they don't get what they want, they vote with their feet. Companies like Facebook and Google stand ready and armed to provide shockingly-efficient services to millions of users who choose them. You could say that with today's network, the autonomy shifted from the network to the users. The nice thing about University-run services is that students can organize and ask for changes, as Fred pointed out. And for people like me, there's something nice about knowing the person who runs your email system. But if your busy university staff doesn't have time to investigate an email server with fast full-text indexing, you might wish for change. Having the university tear down its internal services is a progression toward seeing its network as simply transit. Imagine the loss of pride. It used to be that the university personally ran a system for helping users get what they wanted. As it becomes simply transit, the staff are just greasing the cogs of a larger, invisible machine that's easy for users take for granted. Some netizens like me hold email as sacred, a beautiful institution based on standards and a decision to interoperate. When your university switches to Gmail, I'll be sadder, but maybe what you'll get is professors who can spend more time with students and less time configuring desktop software.

Trade offs Every university has a choice: Pay hundreds of thousands to millions of dollars a year for dedicated staff to run an in-house email system, or let Google do it. Think for a moment of what good could come from those dollars when put to use in other ways for students. Your school could start a switch to all-organic food. It could start paying more of its employees a living wage. Imagine the travel funding for student activities that can come from hundreds of thousands a year well-spent. It could run a massive used textbook clearinghouse to help students avoid pouring their dollars into the textbook industry. And now cry with me. What I've asked you do is to consider sacrificing institutional autonomy for cold, hard cash. That's to say nothing of the ecological benefits or the productivity increases possible from having Google's paid experts run this part of the computing system.

Conclusion Is an official Google email system much different than the reality most students I know live, which is configuring their student email address to forward to gmail.com? For those of us who would be sadder with one more push toward centralizing email with Google -- for those who see it as the behemoth whose size threatens the decentralization that used to be the core of the Internet -- I ask you to think positive. "See the profit from your loss." I have no conclusions for you, just niggling questions.

I propose a new feature for email software: Cosmetic carbon copy. CCC works very similarly to today's carbon copy feature: If you put an address in the CCC: list, when the recipients open the message, they can see the address. The one difference is that with "cosmetic" carbon copy, the CCC:d address never recieves the message. An example might illustrate the situation. Let's say someone (Alice) wants to invite Bob to a movie but doesn't want Charlie to come. She might send this email:

From: alice@example.com
To: bob@example.com
CCC: charlie@example.com
Subject: MOOOVIEEE!

Hey all my friends, join me for a movie tonight!

When Alice sends the email, Bob recives a copy. Bob thinks that Charlie received a copy, as he will be in the CC list. But Alice's mail software never sent Charlie a copy. So Alice can relax, knowing that Bob won't forward a copy to Charlie, since Bob thinks he already received it. Alice and Bob will meet up without Charlie, and Alice will quietly sigh in relief.

How can this work? Cosmetic carbon copy works on the same principle as blind carbon copy: the contents of the message are fundamentally independent from the recipients. Saavy email users have used the "blind carbon copy" feature for years. When you place an address in the BCC list, that address will receive a copy of the email even though other recipients won't see the address listed. This allows for a form of privacy between the sender of the email and that hidden recipient. This works because, like postal mail, email messages are delivered using an "envelope" that contains the actual recipients. When you compose a message in Alpine, Gmail, or Thunderbird, you are writing the contents of the envelope. When you hit send, the mail software looks for email addresses that should receive a copy. It creates one envelope per address, stuffs the letter inside, and sends the whole thing on its way through the Internet using a protocol called SMTP. When the recipient (Bob)'s email system receives it, the letter is pulled out of the envelope and placed in an inbox. Which means the envelope is entirely invisible to Bob, the recipient. Most mail software puts information about the envelope in email headers. Since each email recipient gets a separate envelope, In the case of cosmetic carbon copy, Alice's letter claims that Charlie was on the CC: list. But Bob can never learn that Charlie's copy was never sent. So to implement cosmetic carbon copy, Alice's mail program must understand this rule:

• For each address in the CCC list, copy the message to the CC: list in the email message.
• Create no new envelopes when sending the message.

Because of the last bullet point, this "carbon copying" is purely cosmetic rather than functional.

A possible privacy problem You might wonder, what happens when Bob hits reply-all to say "Yes, I'm coming"? Then (oh no!) Charlie might see the invitation. Not a problem: Most of my friends use Gmail, and Gmail users almost always hit Reply instead of Reply-All. Gmail used to have an experimental option called "Reply All by Default", but thankfully they removed that option. A future version of this specification might suggest mangling the last "." in the BCC:d email addresses with the ONE DOT LEADER character, which looks like "." but isn't one. That way, even if Bob clicks "Reply all," Charlie's email address is subtly incorrect and will bounce.

Future work The story I've told here is marginally simplified so it's understandable to a less-technical audience. Those who want a more technical version can request I submit an RFC. Perhaps in two months? (File under "games to play with email.")

I run a personal server that hosts web space for a few friends. Probably the most popular thing to do with the space is to install WordPress and run a personal blog. A few days ago, I discovered some attackers were abusing one of the sites. Once we upgraded the site to the latest version of WordPress, the attack went away. So I wrote a tool that, every night, emails me a report of the locations of old versions of WordPress. A sample email:

Current version of WordPress: 2.9

oldroommate has WordPress 2.5 in /home/oldroommate/web/oldroommate.com/

Eek! WordPress 2.5 is old!

How it works Each time it runs, it looks at wordpress.org to see what the current version is. The code to do that is written in Python and uses lxml.html. It prints the current version in the report, and it uses it when analyzing WordPress installs. To analyze WordPress installs, it executes locate readme.html, looking for WordPress's tell-tale documentation file. For every such readme.html, if it matches a simple regular expression suggesting it's a WordPress readme file, it performs the following analysis:

• It does some simple seding and greping looking for the version of WordPress described by that file.
• If the version detected is older (as calculated by dpkg --compare-versions), it creates a one-line report like the one above about oldroommate.

If it found any installs of old WordPress, it prints a report like the one blockquoted above to stdout.

How to use it To get emails, I run it with cron. You can add a stanza like this to your crontab (edit it with crontab -e):

@daily cd find-out-of-date-wordpress; ./look.sh

Ta-da, nightly reports.

To get a copy Do a git clone:

git clone git://git.asheesh.org/find-out-of-date-wordpress.git

or browse its gitweb.

Feedback I'm quite interested to hear what others do to avoid old web apps being attacked. If there's another bit of software that monitors web apps for needing upgrades, I'd love to hear about it! Obviously if you have feedback on this tidbit I wrote, let me know. (To me, apt-get doesn't seem to be the answer. Web apps (especially PHP ones) don't usually seem to support keeping the code in one place with multiple different configuration files. And users get excited about the latest and greatest and don't want to wait for me to upgrade, and I can't blame them.) If some of you don't like the Python dependency or anything else, I do welcome patches!

As someone born in India, I sometimes look around and wonder, Where are the Indians (and other South Asians) in Free Software? (I don't mean to exclude South Asians from other countries, so I will lump us together. I believe that we are more similar than we are different, although I know more about India than about the rest of South Asia.) There is no shortage of Indians performing information technology jobs in the United States. The same is true in academia; the Computing Research Association uses National Science Foundation data to show about 15% of computer science bacholor's degrees are awarded to "Asians or Pacific Islanders." These are not precise numbers targeted at South Asians in particular, but they confirm a general feeling that plenty of technologists in the United States are from that part of the world. South Asia is quite a populous region, coming in at over one billion people. It, too, has plenty of technology workers. So much FLOSS conversation happens in English, and India is well-suited to handle this; English is an "official language". Indian academia reports that there are 350 million English users and about 90 million English speakers. So let's visually compare the Debian developers map for South Asia (over one billion people) and that of New Zealand, a country of four million. India: New Zealand: These two countries have about the same number of Debian developers (at least, who have marked their location in the Debian LDAP database). About four. South Asians comprise about one sixth of the world's population. There are about one thousand Debian developers; we represent at best 1% of that. These numbers are comparable to the under-representation of women in Free Software, especially when you compare the figure to South Asians' over-representation in the rest of information technology. That makes me sad. Take a look at the Debian developer map again. You'll see that Debian is certainly not an Americans-only project, or even an English-speakers-only project. South America has a respectable dotting of developers, and Western- to Central-Europe are packed. I have strong feelings about Free Software. It emerges from an ethos of personal empowerment, and with open source it has become a dominant force in computing. Yet there are plenty of sharp people -- at least women and South Asians -- who, somehow, become culturally excluded from participating.

Why care about diversity? Consider the diversity of contributors we already have. Some contribute to Free Software because of particular business needs, such as what caused Avi Kivity to write KVM, the new leader in Linux-based virtualization. Everaldo's art background gave us the "Crystal" icon set that set the standard for sharp-looking icons on the Free Desktop for years. Josh Coalson knew about compressing sound, and his Free Lossless Audio Codec is now the standard in high quality audio. We already have a great deal of diversity. We should be celebrating! Back in 2001, FLAC's users were celebrating. In that year, I decided to ditch proprietary operating systems because I felt I could achieve all my computing needs in the Free world. A happy user of FLAC myself, I lurked on the mailing list as I watched grateful people thank Josh for the great software he wrote. Different contributions will excite different sorts of users. The more different people we have improving FLOSS, the more happy users we can make. Happy users of FLOSS are Free users. Happy users can become contributors, putting forth code, documentation, translations, and word-of-mouth marketing. The first reason to improve diversity in FLOSS is to better suit our users' needs. The more diversity we have in our contributors, the more chance we have of tickling our users in the ways that please them the most. I wish to see an end to software that restricts users' freedom, so I want to see us build the tools that users want. One thing that pleases me is when I see other people contributing who seem similar to me. When I went to Debconf, I was thrilled to be surrounded by people who cared about software freedom and technical excellence. I had even more fun being social, chatting about rainforests, mutual friends, websites, and music. I might have had the most fun playing the card game Mao. A second reason, then, to improve diversity in FLOSS is to increase contributor retention by increasing joy. Mao was an example of a cultural bond I happened to share with a handful of Debianites. The more diversity we have, the more frequent these sorts of coincidences will be. The final, most obvious, reason to reach out to groups of people who do not typically contribute is that we can increase our numbers. That by itself is so valuable. Ubuntu sees 100 new bugs per week, even after the bug squad's efforts. If we can do a better job of recruiting new contributors, the raw numbers give us more strength in creating and maintaining world-class software as well as letting the world know about it.

Changing the balance I believe that there are plenty of South Asians quite capable of contributing to FLOSS. I believe the same of women. I believe the same of men. Back to the topic at hand. Why do the South Asians vanish when we look at Free Software, not tech in general? There are plenty of reasons I can dream up, based on my experience with Indians.

• Plenty of South Asian parents urge their children to make low-risk career choices.
• My mother reports that schools in India focus on memorization instead of creativity. This can leave little room for extracurricular pursuits.

It's tough for FLOSS advocates to work directly on these distant issues. But I think we can focus some problems we can help solve. Crucially, awareness of Free Software spreads best by social circles. I learned about Linux from a friend at a summer camp. I'll repeat that:

• Awareness of Free Software spreads best by social networks.

So if you want to spread that awareness, try to be a bridge. If you meet someone from an unusual background for open source who needs support or mentorship, try to help. That is an investment in the diversity and growth of Free Software. Those people can now unlock more "open source minorities."

What success looks like Google Summer of Code helps some new contributors get started and provides that mentorship. Rachel McCreary was invited to the SciPy conference after a successful summer. Her father left a comment explaining how her sisters participated in FLOSS via Google's Highly Open Participation (GHOP) Contest:

Rachel was inspired and motivated by BOTH of her little sisters, each completing six GHOP tasks (if memory serves).

GHOP and GSOC has been a game-changer for these girls. Rachel's younger sister is applying to schools such as MIT with an interest in a science major. The youngest daughter now has a Caltech poster on her wall with the intent to eventually attend.

Their proud Dad

Soon, these stories will be commonplace. Until then, we have work to do. (I'm still researching these topics. If you can help me find any sort of data to help me learn more about diversity in FLOSS, even if it seems like I wouldn't like it, leave a comment.)

Cross-posted to asheesh.org from the OpenHatch blog. (OpenHatch is my current project.)

"How do I get involved in free and open source software?"

"How do I encourage people to join my project?"

Gregory Wilson, a CS professor at UToronto, cites some recent successes at answering these questions with respect to students: "Google Summer of Code and UCOSP have both shown that it's easier for students to get into open source projects if there s a pile of tiny tickets for them to start with." We believe that these "bite-size" bug lists can benefit all sorts of new contributors, student or not. What you might not know is that more than a hundred projects have these small tasks tagged and waiting for you in their bug trackers.

To make it easier to find these, the OpenHatch volunteer opportunity finder allows you to browse, in one place, nearly 1000 bite-size bugs.

Do you know another project with bite-size opportunities we should index? You can get your project involved. Check out the list of bug trackers we index. If you contribute to a project, go to your bug tracker right now and label a few as bite-size. Then add your bug tracker to our index.

I want to especially thank GNOME for the ongoing GNOME Love effort that is our inspiration and the source of hundreds of these bite-size opportunities.

Happy hacking!

If this sort of thing is interesting to you, take a look at OpenHatch and subscribe to our blog or @openhatchery on Identi.ca or Twitter.